AI 讓功能生成速度變快，也讓模糊需求更快形成具體成果。以前需求寫得不清楚時，開發者會在拆解、設計或實作過程中遇到卡點，再回頭找產品負責人或使用者確認。這些停頓會拖慢開發進度，同時提供重新確認與修正理解的機會。
現在，即使需求存在模糊空間，AI 仍會依照常見模式補上需求中缺少的規則，迅速產生 API、畫面欄位、資料結構、測試案例與錯誤處理。產出看起來完整，團隊也可能因此誤以為需求已經被正確理解。
團隊沿著這套做法繼續開發後，AI 補上的假設會進入程式碼、資料結構與測試案例。原本模糊的需求會變成一個功能完整、邏輯一致，卻不符合實際業務規則的系統。
後續修正時，程式、測試、文件與既有資料都可能被牽動。
需求理解出現偏差時，AI 會讓錯誤方向更快進入開發流程。產品角色原本只描述一個大概想法，開發者透過 AI 很快就能拆出任務、產生程式碼、補上測試，甚至整理文件。
流程看起來進展順利，尚未確認的假設也跟著被送往後續環節。
這類問題常發生在不同角色使用的語言沒有對齊時。產品說「審核通過後通知使用者」，開發者可能理解成系統寄送電子郵件，客服可能以為系統會產生站內通知，使用者期待的則是手機推播。
AI 只能根據輸入內容與常見情境產生結果。輸入中沒有說清楚的地方，會由它自行推測並補上。
錯誤方向進入開發流程後，後續工作也會建立在相同理解上。
測試案例會依照錯誤情境設計，文件會記錄錯誤流程，展示（Demo）也可能演練一個與真實使用情境不符的版本。產出彼此一致時，即使是錯誤假設，團隊仍容易以為功能已經接近完成。等使用者看到成果後才指出問題，修正範圍已經涵蓋需求、程式碼、測試、文件與展示內容。
AI 加快功能生成後，返工範圍也可能隨之擴大。錯誤需求不會停留在需求文件裡，它會迅速進入程式碼、測試、自動化腳本、操作文件與部署準備。
早期少確認一條規則，讓 AI 補充的需求假設擴散後，後續就可能需要調整資料表、修改 API、重寫測試，並重新整理相關文件。
返工也會影響團隊對系統與產出流程的信任。功能看起來已經完成，後來才發現方向有誤，團隊就要重新理解需求、拆除原有設計、確認影響範圍，再補上新的實作。產品、工程、測試與維運也會重新檢查前面產出的可靠性。
功能生成速度提高後，需求確認需要更早進入流程。使用範例、驗收條件、流程草圖、原型（Prototype）與短時間的使用者回饋，都能協助團隊在大量實作前校準理解，找出角色之間的認知差異。
AI 可以縮短想法轉成功能的時間。需求先被正確理解後，程式碼、測試與文件才適合沿著相同方向展開。前段確認越具體，後面的開發速度才不會轉成更大的返工成本。
需求理解落差常從語言差異開始形成。產品角色描述需求時，多半使用業務語言，例如「提高審核效率」、「讓會員方便使用優惠」或「主管需要看到異常案件」。這些說法適合用來討論問題與預期成果，仍需要進一步轉成明確的系統行為。
開發者接到這些描述後，需要拆解其中的流程與規則。審核效率會牽涉狀態流轉、權限設定、通知方式與查詢條件。會員優惠會牽涉折扣計算、適用範圍、排除條件與交易紀錄。異常案件則需要確認資料來源、判斷規則與呈現方式。轉換過程若缺少明確說明，各個角色就會依照自己的經驗補上內容。
AI 介入後，語言差異會更快形成可執行產出。當產品提出「提供主管審核功能」，AI 可能直接生成審核頁面、狀態欄位、權限設定與 API。內容看似齊全，也可能通過基本測試，仍無法證明它符合組織中的審核責任、代理規則、逾時處理與例外流程。
產品語言進入工程流程前，需要先被整理成可驗證的行為描述。團隊可以用具體範例說明誰在什麼條件下執行什麼操作，系統需要產生什麼結果，以及哪些情況需要拒絕、提醒或轉交處理。
當語言轉換成為共同討論的一部分，AI 才能取得明確輸入，後續產出也能依照相同規則接受檢查。
角色之間的理解落差，也常來自沒有說出口的假設。
產品負責人熟悉使用者情境，可能省略他認為大家已經知道的背景。開發者熟悉系統限制，會依照既有架構推論可行做法。測試人員則從風險與例外情境出發，推論其他角色尚未提到的邊界條件。
這些假設若沒有在討論中攤開，就會留在每個人的理解裡。
產品角色可能認為「主管」只包含直屬主管，開發者可能認為主管角色直接取自既有權限表，測試人員則可能把代理主管納入審核範圍。
每一項假設都有合理依據，放進同一項需求後，卻會形成不同版本的功能規則。
AI 會讓這類差異更難被察覺。需求輸入缺少背景時，AI 就會依照常見模式補上狀態和邏輯。
它可能預設審核流程只有待審核、通過與退回，通知方式只有電子郵件，所有主管也共用同一套權限規則。這些推測若沒有被明確標示，就會直接進入程式碼、測試案例與文件。
「我們以為」需要被整理成「已確認事項」。需求討論中可以主動記錄假設、限制與待確認問題，例如哪些角色會使用功能、哪些情境暫不處理、哪些規則仍需要使用者確認。
假設被寫下來並逐項核對後，團隊與 AI 才有明確依據，需求也不會被各自補成不同版本。
需求從使用者進入產品，再從產品交給工程與測試，多半會經過多次交接。每次交接都會重新整理資訊。
使用者原本提供的背景、例外情境與操作困擾，進入需求文件後，可能只剩下幾句功能描述。到了開發任務，又可能被壓縮成一張工單標題與幾條驗收條件。
討論內容需要經過整理，才能轉成可執行的工作。壓縮過程若只保留結論，省略背景與決策理由，後續角色就只能看到最後要做什麼，無法理解當時為何做出這項選擇。
需求交給 AI 產生設計或程式時，缺少的脈絡就會成為 AI 自行推測的空間。
例如使用者原本說：「主管希望看到異常案件，因為有些案件卡在分公司沒人處理。」需求文件可能被整理成「新增異常案件查詢」，到了開發任務中，又被拆成「建立異常案件列表 API」。
開發者看到的是查詢功能，卻不一定知道這項需求關心的是責任歸屬、案件停留時間與提醒機制。AI 根據工單產生內容時，也可能只完成列表，沒有處理真正需要被看見的流程卡點。
要降低交接造成的理解落差，工單需要保留足夠的需求脈絡。除了功能描述，也應留下使用情境、決策理由、重要範例與未決問題。
這些內容能協助團隊理解需求，也能讓 AI 取得更貼近現場的上下文。輸入內容越接近真實情境，產出越不容易停留在表面描述。
錯誤需求最容易在功能完成後被看見。開發過程中，團隊可能已經完成畫面、API、資料表、測試案例與基本流程，展示時也能順利操作。等產品負責人、使用者或客服實際檢視後，才發現功能可以執行，內容卻沒有貼近真實工作場景。
例如需求只寫著「主管可以審核申請單」，AI 便協助產生審核頁面、通過與退回按鈕，以及審核紀錄。功能看起來完整，後續才發現真實流程中的主管並非固定角色。有些申請會依金額交由不同層級審核，主管請假時需要由代理人處理，部分退回案件還要重新送簽。
這些規則若在開發前沒有確認，後續補入時就會牽動整套流程設計。
這類返工很少只需要修改幾個欄位。狀態流轉、權限判斷、通知條件、資料紀錄與操作畫面都要重新核對，原有程式碼、測試案例與文件中建立在錯誤假設上的內容也要被找出來。
修復成本會隨著問題進入不同階段而提高。需求階段的修復成本約為 1x，進入寫程式階段後提高至 5x，測試階段約為 15x，上線後則可能達到 100x。
AI 縮短了功能從需求描述進入可執行狀態的時間，也讓尚未確認的規則更快進入系統，使問題從 1x 修復成本階段進入 100x 階段的速度縮短約 80%。需求偏差在功能完成後才被發現時，拆除與重建的範圍也會跟著擴大。
需求理解出現錯誤時，測試案例也會沿著相同方向設計。測試人員會根據需求描述、驗收條件與系統設計準備測試。
前面的需求方向若已經偏離真實情境，測試案例驗證的也會是錯誤行為。最後測試全部通過，只能證明系統符合當時的理解，無法證明功能符合使用者需求。
AI 生成測試案例時，這個問題會更加明顯。需求輸入不完整時，AI 會依照常見流程補上成功情境、失敗情境與邊界條件。這些案例格式完整，也能直接轉成自動化測試。團隊若沒有回到使用情境檢查，AI 補上的假設就會被寫進測試資料、斷言、預期結果與自動化測試。
錯誤測試案例進入回歸測試後，後續修正範圍也會擴大。需求調整時，團隊除了修改程式碼，還要重新整理測試資料、測試腳本、驗收條件與相關文件。
原先用來保護系統行為的測試，會變成繼續要求系統維持錯誤流程的枷鎖。
這時要重新檢查每一項測試所依據的需求背景，判斷哪些案例仍能代表真實情境，哪些案例套用了先前的錯誤理解。測試可靠性是建立在需求依據與使用情境的確認之上。
錯誤需求進入正式環境後，返工成本會進一步提高。功能已經被使用者看到，也可能產生資料、通知、權限紀錄與操作習慣。
此時的修正會影響客服、維運、管理者與實際使用者，處理範圍也會超出開發團隊。
例如錯誤的優惠計算規則上線後，可能已經套用在多筆訂單中。團隊除了修正程式，還要確認既有訂單是否需要補差額、是否要通知使用者、客服應該如何回覆，以及財務報表與對帳資料是否受到影響。
早期只需要釐清的一條規則，進入正式環境後，就會轉成跨角色的補救工作。
AI 能讓錯誤需求更快到達可部署狀態，因此上線前的需求驗證密度也要提高。功能開始大量實作前，應讓使用者提早檢視流程草稿、操作原型與具體範例。測試通過前，也要確認測試案例所驗證的行為符合真實需求，並檢查資料處理、通知、權限與例外流程是否完整。
需求理解先經過校準後，程式碼、測試與部署準備才有一致依據。前段核對越充分，開發速度越能轉成有效交付，也能減少上線後的資料修正、使用者溝通與跨部門補救成本。
早期驗證的第一步，是把抽象需求轉成可討論的範例。需求若只寫著「主管可以審核申請單」，不同角色會帶入各自的理解。產品負責人想到使用者流程，開發者想到狀態與權限，測試人員則會注意例外情境。這些理解需要放在同一個情境中共同確認。
範例能讓差異提早被看見。例如「員工送出新台幣 3,000 元以下的申請單時，由直屬主管審核」、「金額超過新台幣 3,000 元時，需要部門主管與財務主管依序審核」、「主管請假時，系統改由代理主管處理」。這些描述能呈現角色、條件、行為與預期結果，也能讓團隊檢查是否還有遺漏的規則。
在 AI 參與開發的流程中，範例也能縮小推測空間。團隊可以把範例整理成行為規格，使用 Gherkin（Given-When-Then）形式描述，再提供給 AI 作為生成上下文。AI 產出的畫面、API、權限邏輯與測試案例，都可以回到相同範例逐項檢查。
範例越貼近真實工作情境，團隊越能提早發現理解差異。AI 也能根據明確規則產生內容，減少功能符合字面描述卻偏離實際流程的情況。
需求理解落差常要等到具體成果出現後，才容易被指出來。使用者聽到口頭說明時，可能覺得整體方向合理。看到畫面草稿、流程圖或可點擊原型後，才會發現欄位順序不符合操作習慣、狀態名稱與日常用語不同，或某個步驟放進實際工作後很難執行。
草稿不需要做到很細。低保真原型（Low-fidelity Prototype）、流程草圖、表單範例、假資料畫面，甚至一段文字形式的操作劇本，都能協助使用者提早提供回饋。大量程式碼完成前，使用者應先看見需求將如何形成畫面、操作步驟與工作流程。
AI 能快速產生草稿，適合放在需求驗證的前段。團隊可以請 AI 根據需求整理畫面欄位、流程步驟與操作情境，再將內容交給使用者檢視。使用者提出的修正才能回到需求描述與行為規格中，成為後續設計、開發與測試的依據。
先用 AI 產生可討論的素材，能讓團隊提早發現語言差異與隱性假設。等角色、流程與規則經過確認後，再進入正式實作，後續產出會更貼近真實工作情境。
早期驗證需要成為團隊的固定節奏。需求確認若只依靠開發前的一次會議，仍可能遺漏流程細節與例外情境。
需求應在討論、設計與試用過程中持續補充與校正，固定的檢查時間可以把新發現的問題帶回來確認。
在短衝（Sprint）或看板（Kanban）流程中，團隊可以在需求進入開發前，檢查具體範例、驗收條件與未決問題。
開發期間也能安排短時間的需求校準，讓產品、工程與測試共同確認目前的設計與實作方向。功能出現草稿或可操作版本後，應盡早讓使用者檢視，提早發現流程、規則與操作上的偏差。
AI 也可以加入需求驗證流程，扮演質疑者的角色。在進入開發前，要求 AI 從測試人員或極端使用者的角度檢查需求，主動找出尚未定義的情境。例如請 AI 列出這份需求中缺少的邊界條件、例外處理、權限限制或特殊流程，協助團隊發現原本沒有討論到的假設。
這套節奏也需要連接 AI 的使用方式。AI 產出的畫面、程式碼、測試案例或文件進入開發流程前，團隊應先確認內容是否符合範例、驗收條件與已確認的業務規則。
AI 補上的狀態、權限、通知或例外處理若缺少需求依據，就要標示為待確認假設。
當需求驗證成為日常流程的一部分，新發現的資訊就能回到需求、設計與測試中。理解偏差也能在範圍較小時被修正，減少一路延伸到回歸測試、部署與正式上線的機會。
iThome鐵人賽
看影片追技術